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METHOD AND APPARATUS FOR PROVIDING USER MULTIPLEXING IN A REAL-TIME PROTOCOL 

5 BACKGROUND OF THE INVENTION 

1. Field of the Invention. 

This invention relates in general to a IP telephone, and more particularly to a 
method and apparatus for providing efficient user multiplexing in a real-time 
protocol payload for transporting compressed speech between IP telephony 
10 gateways. 

2. Description of Related Art . 

An organization's computer network has become its nervous system. 
Organizations have combined desktop work stations, servers, and hosts into Local 
Area Network (LAN) communities. These Local Area Networks have been 
1 5 connected to other Local Area Networks and to Wide Area Networks (WANs). It 
has become a necessity of day-to-day operation that pairs of systems must be able 
to communicate when they need to, without regard to where they may be located in 
the network. 

During the early years of network computing, proprietary networking 
20 protocols were the standard. However, the development of the Open Systems 

Interconnection Reference Model introduced by the International Organization for 
Standardization (ISO) has led to an impressive degree of interworking, which 
generally allows end-user applications to work very well between systems in a 
network. Implementations are based on written standards that have been made 
25 available by volunteers from dozens of computer vendors, hardware component 
vendors and independent software companies. 

During the last decade, LANs have been proliferating. This has created a 
recurring problem of how to minimize congestion and optimize throughput that must 
be solved by network managers. An early solution was to simply divide Local Area 
30 Networks into multiple smaller networks serving smaller populations. These 
segments were connected by bridges to form a single Local Area Network with 
traffic being segregated locally to each segment. 

An Internet is a set of networks connected by gateways, which are sometimes 
referred to as routers. The Internet Protocol (IP) is a network layer protocol that 

1 
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routes data across an Internet. The Internet Protocol was designed to accommodate 
the use of host and routers built by different vendors, encompass a growing variety 
of growing network types, enable the network to grow without interrupting servers, 
and support higher-layer of session and message-oriented services. The IP network 
5 layer allows integration of Local Area Network "islands' 1 . 

The Internet not only provides a medium for data transport, but also has 
developed as a medium for telecommunications. In fact, IP telephony is maturing as 
a technology and a service, which places it in direct conflict with the conventional 
public telephone network. New types of IP telephony equipment are being 

10 introduced and small Internet service providers and niche carriers are beginning to 
offer IP telephony services. 

However, while IP telephony, or voice-over-IP, has great potential to 
compete against the traditional public voice network, many obstacles must first be 
overcome. For example, the quality of Internet telephone calls is not as good as 

1 5 public network calls. Customer interest in the United States-where long-distance 
prices have consistently fallen-is uncertain. Further, IP telephony network 
equipment is new and lacks features that carriers desire. 

Consequently, only a handful of small telephone companies now offer IP 
telephony services, and the amount of traffic they carry is minimal However, 

20 equipment vendors and carriers are moving quickly to overcome these problems and, 
according to analysts, the number of established carriers beginning IP telephony 
trials is rising rapidly, new carriers are jumping into the market and the number of 
services being offered is expected to increase dramatically. In fact, analysts predict 
that users will embrace the new IP~based voice services. 

25 Accordingly, the success of Internet has further consolidated the notion that 

IP is the dominant transport protocol in access networks. The penetration of Internet 
and subsequent IP connectivity to homes and businesses have given impetus to 
integrated services over IP which means voice, data and video over a single IP 
network. At present, IP networks offer a single class of service called best effort, 

30 which can not guarantee any Quality of Service (QoS) to applications. To support 
delay sensitive applications such as voice and interactive multimedia, there have 
been many proposals submitted to the Internet Engineering Task Force (IETF) on 
how to integrate QoS in IP networks. These proposals include differentiated service 
(diff-serv), Integrated services (Int-serv) and Multi Protocol Label Switching 
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(MPLS). Despite these efforts, QoS in IP is still elusive and could take some time 
before it is deployed over global Internet. 

As mentioned above, IP telephone has emerged as a potential application to 
challenge the traditional phone companies by offering long distance telephone 
5 service over Internet for low prices. There are a large number of equipment vendors 
offering IP telephone gateways and accessories to provide IP telephony service to 
corporate customers and Internet Service Providers (ISPs). IP telephone standards 
such as H.323, H.225 and H.245 have been standardized to enhance the rapid 
deployment of IP telephone services in global Internet. Even though, IP telephone is 

10 not a reality in public Internet today, it has been successful in Intranet and Virtual 
Private Networks (VPN) environments. 

There is a strong indication that IP telephone will be a niche service once 
QoS issues in IP networks become a reality. However, IP networks offer only best 
effort service, whereas delay sensitive applications such as voice and interactive 

15 video require a deterministic guarantee on the delay, delay variation and packet loss 
from the network. As can be seen then, this lack of QoS guarantee in IP networks is 
touted as the major problem to provide real time services such as IP telephone over 
Internet. To overcome the delay problem in the Internet, IP telephone providers over 
provision the links (networks) that interconnect IP telephone gateways. This 

20 additional bandwidth enables the IP packets to be transmitted with less delay thus 
providing a reasonable voice quality. It has been demonstrated in Intranet as well as 
VPNs that IP telephone services can match the voice quality offered by traditional 
telephone networks. As a result, the growth of IP telephone gateways in corporate 
and ISP environments is expected to increase exponentially in the coming years. 

25 Traditionally voice is carried in a circuit switched network with connection 

oriented model. The explosive growth of data traffic in the network has changed the 
notion of service specific networks (single network for single service). Voice over 
IP network enables the voice traffic from public branch exchanges (PBX) and public 
switched telephone network (PSTN) users to share the data network thus improving 

30 the network utilization and lowering the cost associated with long distance telephone 
network. IP telephone gateways act as an interface between the existing PSTN and 
PBX networks and IP networks. This method allows one PSTN user to call another 
PSTN user connected through IP telephone gateways thus eliminating the need for 
long distance telephone network. 
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In a IP telephony connection, two sides of the PSTN/PBX users (two 
branches of the same company) are interconnected by IP telephone gateways. In 
such application, a telephone call between PSTN/PBX users located at either side of 
the gateways is carried by a separate Real-time Transport Protocol/User Datagram 
5 Protocol/Internet Protocol (RTP/UDP/IP) connection. RTP is an Internet protocol 
for transmitting real-time data such as audio and video. RTP itself does not 
guarantee real-time delivery of data, but it does provide mechanisms for the sending 
and receiving applications to support streaming data. Typically, RTP runs on top of 
the UDP protocol, although the specification is general enough to support other 

10 transport protocols. The User Datagram Protocol is a connectionless protocol that, 
like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few 
error recovery services, offering instead a direct way to send and receive datagrams 
over an IP network. 

IP telephony gateways provide an interface between the existing circuit 

15 switched telephone networks (such as PSTN and GSM) and the packet switched IP 
data networks. In traditional IP telephony applications, telephone calls between 
PSTN users interconnected by a pair of IP telephony gateways to compress incoming 
PSTN speech samples generate packets with sizes ranging from 5 to 20 bytes per 
speech sample. 

20 For example, G.723.1 (the most popular IP telephony codec and the 

International Multimedia Teleconferencing Consortium's (IMTC) Voice over IP 
(V oIP) mandatory low bit-rate codec), generates a 20 byte speech packet at 30 ms 
intervals. Many codecs used in cellular environment generate less than 10 byte 
packet per speech sample. Small size packets are subjected to large overhead when 

25 transferred using the Real time Transport Protocol (RTP). The RTP/UDP/IP 

overhead is 40 bytes (12+8+20) for a simple speech packet. For example, a 10 byte 
packet transferred via RTP/UDP/IP increases the overhead to 80% (40 byte 
overhead/50 byte overhead plus packet). In addition, for each call request a single 
UDP/IP connection (a pair of UDP ports) is established between the gateways 

30 requiring a large state (memory) to be maintained at the telephony gateways, thereby 
making these less scaleable. 

Congestion in IP networks results in packet loss at routers and UDP does not 
have any retransmission mechanism to recover lost packets. Also, real time 
applications such as speech is intolerant to delay caused by re-transmission. In 

35 traditional RTP method, each individual speech packet is transmitted as a IP packet, 
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which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss at IP routers. 

It can be seen then that there is a need for a method and apparatus for 
eliminating inefficiencies in transporting short packets between IP telephony 
5 gateways connected by an IP network. 

It can also be seen that there is a need for a method and apparatus that 
enables a number of users to share a single RTP/UDP/IP connection. 



SUMMARY OF THE INVENTION 

10 To overcome the limitations in the prior art described above, and to 

overcome other limitations that will become apparent upon reading and 
understanding the present specification, the present invention discloses an efficient 
real-time transport protocol multiplexing method and apparatus for transporting 
compressed speech between IP telephony gateways. 

15 The present invention solves the above-described problems by providing a 

method and apparatus for eliminating inefficiencies in transporting short packets 
between IP telephony gateways connected by an IP network, wherein the method and 
apparatus enables a number of users to share a single RTP/UDP/IP connection. 

A protocol in accordance with the principles of the present invention includes 

20 creating a header for a plurality of data packets, each header providing identification 
of a user associated with a packet, adding each header to the data packet associated 
therewith to form mini-IP payloads, multiplexing the mini-IP payloads into a RTP 
payload and transmitting the RTP payload over a single RTP/UDP/IP connection. 
Other embodiments of a system in accordance with the principles of the 

25 invention may include alternative or optional additional aspects. One such aspect of 
the present invention is that the plurality of data packets are received from two or 
more users. 

Another aspect of the present invention is that the identification of a user 
further comprises a unique channel identifier for each of the two or more users, 
30 Another aspect of the present invention is that the channel identifier is 

assigned to packets from a user when the user requests access to the IP telephone 
network. 

Another aspect of the present invention is that the header comprises a length 
indicator, the length indicator indicating the size of the data packet associated with 
35 the header. 
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Another aspect of the present invention is that the length indicator comprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

Another aspect of the present invention is that the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 
5 user to identify data packet loss. 

Another aspect of the present invention is that the sequence number further 
comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

Another aspect of the present invention is that the header of each data packet 
10 multiplexed into the RTP payload is transparent to intermediate IP routers. 

Another aspect of the present invention is that the protocol further includes 

de-assembling the RTP payload back into the data packets. 

Another aspect of the present invention is that the protocol further includes 

receiving at a local gateway an access request from a user at a remote IP gateway, 
15 transmitting a setup message to the remote IP gateway using an IP connection and 

establishing a user plane connection for receiving data packets from a user after 

successful completion of a connection setup. 

Another aspect of the present invention is that the protocol further includes, 

after receiving an access request from a user, determining whether an existing 
20 RTP/UDP/IP connection is available, using an existing RTP/UDP/IP connection 

when an existing RTP/UDP/IP connection is determined to be available, creating a 

new RTP/UDP/IP connection when an existing RTP/UDP/IP connection is 

determined not to be available and creating a setup message using a local UDP port 

number, remote port number, channel identifier. 
25 Another aspect of the present invention is that the protocol further includes 

recovering, at the remote gateway, a local UDP port number, remote port number, 

channel identifier from the setup message, verifying at the remote gateway whether 

the channel identifier is free and accepting the connection when the channel 

identifier is free. 

30 Another aspect of the present invention is that the accepting the connection 

further includes updating a channel identifier table at the remote gateway and 
replying to the local gateway with a connect message. 

Another aspect of the present invention is that the protocol further includes 
replying to the local gateway with a rejection message when a problem allocating the 

35 connection occurs. 
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Another aspect of the present invention is that the protocol further includes 
receiving at the local entity the connect message, confirming at the local entity the 
channel identifier and informing the user requesting access. 

Another aspect of the present invention is that the protocol further includes 
5 controlling the multiplexing and transmitting of the RTP payload using a timer. 
- Another aspect of the present invention is that the data packets include 
compressed voice data. 

An IP telephone network according to the present invention includes a 
remote IP gateway and a local IP gateway, wherein the remote and local IP gateways 
1 0 communicate using the protocol. 

A MINI-IP controller according to the present invention includes means for 
providing control plane signaling, control plane signaling being used to setup a 
connection to a remote peer MINI-IP controller and means for providing user plane 
signal, user plane signaling being used to transmit data packets to a user associated 
1 5 with the remote peer MINI-IP controller using the protocol. 

An RTP payload according to the present invention includes an RTP header, 
a plurality of data packets representing data from a plurality of users and a plurality 
of MINI-IP headers, each of the plurality of packets having a MINI-IP header 
attached thereto, each of the MINI-IP headers comprising a user identifier for 
20 identifying one of the plurality of users being associated with each of the packets, 
and each MINI-IP header and packet combination forming a MINI-IP payload, the 
MINI-IP payloads being multiplexed together to form a RTP packet. 

A base station, base station controller and mobile switching center according to 
the present invention include a MINI-IP controller that eliminates inefficiencies in 
25 transporting packets using the MINI-IP protocol. 

These and various other advantages and features of novelty which characterize 
the invention are pointed out with particularity in the claims annexed hereto and form a 
part hereof. However, for a better understanding of the invention, its advantages, and 
the objects obtained by its use, reference should be made to the drawings which form a 
30 further part hereof, and to accompanying descriptive matter, in which there are 

illustrated and described specific examples of an apparatus in accordance with the 
invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

Fig. 1 shows an application scenario in which two sides of the PSTN/PBX 
5 are interconnected by IP telephone gateways; 

Figs. 2a-b illustrate MINI-IP headers according to the present invention; 
Fig. 3 illustrates the multiplexing of MINI-IP pay loads in a RTP packet 
using the MINI-IP header; 

Fig. 4 illustrates the location of the MINI-IP controller in a IP telephone 
10 layered model; 

Fig. 5 illustrates the user plane and control plane in a MINI-IP gateway 
environment; 

Fig. 6 illustrates an example of a CID table; 

Fig. 7 illustrates the use of the TIMER_MUX according to the present 
15 invention; 

Fig. 8 illustrates the application of MINI-IP being restricted to transport 
voice users between IP telephony gateways; 

Fig. 9 illustrates the application of a MINI-IP controller in a radio access 
network; 

20 Fig. 10 is a plot of the number of users on a single RTP/UDP/IP connection 

versus the bandwidth in Kbps for G.723.1; 

Fig. 1 1 is a plot of the number of users on a single RTP/UDP/IP connection 
versus the bandwidth in Kbps for G.729; and 

Fig. 12 illustrates a comparison of the percent overhead verses the number of 
25 users for different methods. 

DETAILED DESCR IPTION OF THE INVENTION 
In the following description of the exemplary embodiment, reference is made 
to the accompanying drawings which form a part hereof, and in which is shown by 
30 way of illustration the specific embodiment in which the invention may be practiced. 
It is to be understood that other embodiments may be utilized as structural changes 
may be made without departing from the scope of the present invention. 

The present invention provides a an efficient method and apparatus for 
transporting short packets such as compressed speech packets between IP telephony 
35 gateways connected by a IP network. The present invention enables a number of 
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low bit rate connections (compressed speech) to share a single RTP/UDP/IP 
connection, thus reducing the RTP/UDP/IP overhead. A MINI-IP header (2 byte) is 
added to each packet from an user before it is assembled with packets from other 
users into an RTP payload. To identify individual users on a single RTP/UDP/IP 
5 connection, a unique Channel Identifier (CID), as a part of the header, is proposed. 
Channel ID negotiations between the peer gateway entities is carried out by a new 
signaling procedure called MINI-IP signaling. Analytical results show that the 
MINI-IP method reduces the overhead for short packets by 60% thus improving the 
bandwidth efficiency. Other advantages of the present invention include a decrease 
10 in the number of UDP/IP connections between gateways and a decrease in the traffic 
congestion at intermediate IP routers. The present invention may be implemented, 
for example, in IP telephone gateways, Radio Access Network (RAN) access nodes, 
and IP access nodes by simply adding an external MINI-IP control module. The 
MINI-IP method uses the existing bearer protocols such as RTP, TCP, UDP ad IP 
1 5 and does not require any changes to the traditional IP network functionalities. 

Traditionally voice is carried in a circuit switched network with connection 
oriented model. The explosive growth of data traffic in the network has changed the 
notion of service specific networks (single network for single service). Voice over 
IP network enables the voice traffic from PBX and PSTN users to share the data 
20 network thus improving the network utilization and lowering the cost associated 
with long distance telephone network. IP telephone gateways act as an interface 
between the existing PSTN and PBX networks and IP networks. This method 
allows one PSTN user to call another PSTN user connected through IP telephone 
gateways thus eliminating the need for long distance telephone network. 
25 Fig. 1 shows an application scenario 100 in which two sides of the 

PSTN/PBX 100, 1 12 (two branches of the same company) are interconnected by IP 
telephone gateways 120, 122. In such an application, a telephone call between 
PSTN/PBX users 1 10, 1 12 located at either side of the gateways 120, 122 is carried 
by a separate RTP/UDP/IP connection. The codecs used at the telephone gateway to 
3 0 compress incoming PSTN/PBX voice calls generates packets with a size ranging 
from 5 to 20 bytes. 

For example, the IP telephone standard G.723.1 specifies a codec that 
generates a 20 byte packet at the interval of 30 ms speech sample. Many codecs 
used in cellular environments generate a small packet, e.g., on the average a 10 byte 
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packet per speech sample. This small size packets require a large overhead when 
they are transferred using the Real time Transport Protocol (RTP). 

The RTP/UDP/IP overhead is 40 bytes (12+8+20) for each speech packet. 
For example, if a 10 byte packet is transferred via RTP/UDP/IP then the overhead is 
5 80%, i.e., 40/50. In addition, for each call request a single UDP/IP connection is 
established between the gateways 120, 122 requiring a large number of states 
(memory) to be maintained at the telephone gateways 120, 122. 

Congestion in IP networks results in packet loss at routers and UDP does not 
have any retransmission mechanism to recover lost packets. Also, real time 

10 applications such as speech are intolerant to delay caused by re-transmission. In a 
traditional RTP method, each individual speech packet is transmitted as a IP packet, 
which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss at IP routers. 

The large overhead to transfer a small packets (compressed speech) through 

1 5 RTP/UDP/IP has been one of the drawbacks of IP telephone. In order to minimize 
the overhead, RTP/UDP/IP header compression is applied for slow speed links. 
However, this method requires compressing/decompressing at routers as well as 
some additional processing overhead. 

Figs. 2a-b and 3 illustrate the use of MINI-IP headers to reduce header 

20 overhead according to the MINI-IP protocol. According to the present invention, no 
compression is utilized, yet an equal or better bandwidth efficiency is achieved. 
Overhead is reduced by multiplexing two or more (e.g., up to 256) low bit rate 
connections in a single RTP/IP/UDP connection using a MINI-IP header 202 as 
illustrated in Fig. 2a. Alternatively, overhead may be reduce using the MINI-IP 

25 header 204 illustrated in Fig, 2b. However, those skilled in the art will recognize 
that the present invention is not meant to be limited to the particular MINI-IP 
headers illustrated in Figs. 2a-b, but that the MINI-IP headers 202, 204 illustrated in 
Figs. 2a-b are presented for illustration only. Rather, those skilled in the art will 
recognize that the MINI-IP headers 202, 204 enables multiplexing of multiple small 

30 size packets, and is added to each mini packet before it is assembled with other mini 
packets as an RTP pay load, as illustrated in Fig. 3. 

To identify a single user among the number of users sharing the RTP 
connection, each user is allocated an unique Channel Identifier (CID) which is 
negotiated during connection setup. The CID negotiation procedures is carried out 

35 by MINI-IP signaling, which uses a TCP/IP connection for reliable transport. The 
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most suitable application scenarios for MINI-IP method include IP telephone 
gateways connecting PSTN/PBX/GSM users. 

To identify mini packets multiplexed on a single RTP payload, MINI-IP uses 
a two byte header, called MINI-IP header, for each mini packet. The MINI-IP 
5 header 202, as shown in Fig. 2a includes a Channel Identifier (CID) 21 0, a Length 
Indicator (LI) 212, and a Sequence Number (SN) 214. The MINI-IP header 202 
allows many users to share a single RTP/UDP/IP connection thus reducing the 
RTP/UDP/IP overhead per packet. 

As illustrated in Fig. 2a, the MINI-IP header includes a CID field 210, which 
1 0 identifies a single user among users haring a single RTP/UDP/IP connection. A CID 
210 is assigned at the time of the request for access to the IP network and it is 
unchanged throughout the connection time. The length of the CID field 210 is 8 
bits, which limits the number of users per single RTP connection to 256. 

The LI field 212 indicates the size of the payload (speech packet) and the 6 
1 5 bits allow a maximum of 64 byte payload. The variable size of the LI field 2 1 2 
allows different codecs to share a single connection and offers the flexibility to 
transport any low bit rate connection using MINI-IP method. The size of the LI 
field 21 2 is limited to 64 bytes since most of the codes available today (G.723. 1 , 
G.729) generates packets less than 20 bytes per speech sample. 
20 The 2 bit Sequence Number (SN) field 2 14 is used for marking the voice 

packets transmitted from a single user in modulo 4 method, which can be used at the 
receiver to identify any packet loss. The module 4 scheme will be able to identify up 
to 3 consecutive packet losses at IP layer. 

The MINI-IP header 204, as shown in Fig. 2b includes a Channel Identifier 
25 (CID) 210, a Length Indicator (LI) 212, a Transition bit (T) 216 and a Reserved bit 
(X) 218. The Channel Identification (CID) 210 in Fig. 2b is an 8 bit field which 
allows a maximum of 256 users to share a single RTP/UDP/IP connection. When 
the total number of users exceeds 256, a new RTP/UDP/IP connection is established. 
The LI field 212 is a 6 bit field which allows a maximum payload size of 64 bytes. 
3 0 The Transition bit (T) 2 1 6 is used to identify any change in processing that was 
applied to a mini-packet. Notification of such changes occurs by toggling the bit. 
Finally, the Reserved bit (X) 218 is currently undefined, but may be used, for 
example, as an indication of a header extension and Dual Tone Multi-Frequency 
(DTMF). 
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As mentioned above, those skilled in the art will recognize that the above 
illustration of MINI-IP headers is not meant to limit the invention, but that other 
MINI-IP header configurations and sizes could be used in accordance with the 
present invention. For example, the length of the fields could be modified within the 
5 2 byte format. Further, other fields could be substituted and the length of the fields 
is not meant to be limited to provide a MINI-IP header of 2 bytes. For example, the 
reserved bit illustrated in Fig. 2b may be set to "1" to indicate an extension head is 
included in the MINI-IP header thereby providing an overall length for the MINI-IP 
header of 3 bytes. Alternatively, the reserved bit may be set to "0" to indicate that an 

10 extension header is not included in the MINI-IP header. Nevertheless, those skilled 
in the art will recognize that increases in the overall size of the MINI-IP header will 
proportionally increase the total overhead when multiple MINI-IP packets are 
multiplexed together in accordance with the invention. Thus, those skilled in the art 
will recognize that any MINI-IP header that enables multiplexing of multiple small 

15 size packets, is added to each mini packet before it is assembled with other mini 
packets as an RTP pay load as illustrated in Fig. 3, and which allows proper 
processing of the multiple mini packets may be used without departing from the 
scope of the present invention. 

The assembly of mini packets into a single RTP/UDP/IP payload 300 is 

20 shown in Fig. 3 . The mini packets 310 follow the RTP header 312 and each mini 
packet 320 is delineated by the two byte MINI-IP header 312, This approach 
requires a simple de-multiplexing algorithm at the receiver. Because the MINI-IP 
header 3 12 in the RTP payload 300 is transparent to the intermediate IP routers, the 
MINI-IP according to the present invention does not cause any problems in terms of 

25 IP packet forwarding and other functionalities at the IP layer. The traditional Header 
Error Controls (HEC) found in many protocols is excluded because MINI-IP relies 
on the higher layer checksum (UDP checksum) to protect the headers and payload 
from any transmission errors. 

The MINI-IP controller is the key element which will be added to a IP 

30 telephone gateways to implement the MINI-IP method. The major function of the 
MINI-IP controller are: 

i. Negotiate channel identifier with remote gateway upon a 
connection request 

35 Multiplex speech packets from a number of users into a single 

RTP payload 
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iii. De-assemble MINI-IP packets from the RTP payload 

iv. Communicate to the remote controller to forward any request 
and/or control message 

5 The location of the MINI-IP controller 410 in a IP telephone layered model 

400 as shown in Fig. 4. The MINI-IP controller 410 is inserted between the IWF 
function (not shown) of the PSTN/GSM/PBX network 420 and the RTP module 422 
in the IP telephone gateway. The MINI-IP controller 410 is capable of receiving 
connection request from PSTN/GSM/PBX users 420 and setting up a channel on an 

10 existing or a new RTP/UDP/IP connection. The MINI-IP controller 410 acts as an 
application to the layers below 422, 424, 426, 428 (RTP/UDP/IP) and uses the bearer 
services offered by the lower layers for effective multiplexing. Other functions cf 
the controller include open and close RTP/UDP connections, keep track of the active 
users on all UDP connections, and provide inter-working with PSTN/GSM/PBX 

15 call control features. 

The user plane 510 and control plane 520 in a MINI-IP gateway environment 
500 are shown in Fig. 5. The control plane signaling 520 is needed because peer 
entities required to negotiate a channel for an "incoming call request" on an existing 
or on a new RTP/UDP connection. For example, a setup message will be 

20 transmitted upon receiving a call request from a PSTN/GSM/PBX user 530. The 
setup message include UDP connection identifiers and CID. The control signaling 
520 is carried by a TCP/IP connection 540 for assured data transfer. The user plane 
510 association is made after a successful connection setup. The user plane 510 data 
is carried over RTP/UDP/IP layers 542 similar to the audio and video transport over 

25 IP networks. 

The MINI-IP signaling works as follows. A call request from 
PSTN/PBX/GSM user 530 triggers a CID setup sequence between the peer MINI-IP 
controllers 550, 552. First, the MINI-IP controller 550 verifies if there is any 
existing RTP/UDP/IP connection to the remote gateway 560. If there is none or any 

30 existing connection(s) is full (no free CID) then the MINI-IP controller 520 

establishes a new RTP/UDP/IP connection. The new UDP connection is established 
throughout UDP sockets. If there exists a UDP connection and free CIDs for the call 
request, then MINI-IP uses the same UDP port number. A setup message is created 
with the local UDP port number, remote UDP port number, and CID number, and is 

35 transmitted to the remote gateway. 
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The remote gateway 560 recovers the information within the setup message 
and verifies that the requested CID is still free on its local table. If the call can be 
accepted then the local gateway 562 updates its local CID table and replies with a 
connect message. 

5 Fig. 6 illustrates an example of a CID table 600. In the CID table 600 of Fig. 

. 6, CID 25 610 is assigned and CID 26 612 is idle. The local UDP port number 620, 
remote port number 622, local user ID 624 and remote user ID 626 are provided for 
each CID that has been assigned. 

Referring again to Fig. 5, if the remote gateway 560 experiences any problem 

10 in allocating the connection, such as CID collision, then it transmits a reject 

message. The CID collision problem can be solved by existing schemes used in 
other protocols. Upon receiving a connect message, the local entity 562 confirms 
the CID association and informs the corresponding user 530. The MINI-IP 
signaling is closely associated with the call control signaling used in 

15 PSTN/GSM/PBX networks. The MINI-IP controller 550 establishes a user channel 
only within the IP network. Those skilled in the art will recognize that the call 
control signaling outside the IP network is beyond the scope of MINI-IP controller. 

At the time of assembling mini packets into an RTP payload, a timer controls 
the waiting time between the placement of a first packet in the RTP payload and the 

20 time to transmit the first packet to the remote peer. This timer (TTMER_MUX) is 
essential to control the delay accumulated at the multiplexing end for voice packets. 

Fig. 7 illustrates the use of the TIMER_MUX 700 according to the present 
invention. In Fig. 7, mini-packets 710 are received at a scheduler 712. The 
scheduler schedules packets for assembly into an RTP payload by placing packets 

25 into a packet assembly buffer 720. Upon expiration of the TIMER_MUX 730, an 
RTP packet is transmitted. The TTMER_MUX value depends on the link speed and 
transfer delay. The higher the TIMERJtfUX value the better the bandwidth 
efficiency. However, higher TIMER_MUX value could increase the delay for voice 
packets. 

30 Speech is somewhat tolerant to packet loss when compared to data. But, 

beyond a certain limit, packet loss renders the speech inaudible and causes 
inconvenience to the user. Communication media are not error free and any data 
transmitted needs some sort of protection. Existing protocols such as ATM, IP and 
AAL2 specify a Header Error Correction (HEC) to detect errors in the headers at the 

35 receiver. Protocols such as UDP offers both header and payload protection. The 
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UDP checksum is calculated for the entire UDP packet including header and 
pay load. The MINI-IP header is 2 byte long and does not have any HEC field 
because MINI-IP packets are encapsulated within an RTP/UDP payload thus 
protected by the UDP checksum. 
5 Packet loss is another problem that is prevalent in any packet switching 

network. Since MINI-IP enables many users to share a single RTP/UDP/IP 
connection, MINI-IP can not use the RTP sequence number to identify packet loss 
of a single user. To solve this problem, the MINI-IP header consist of a two bit 
Sequence Number (SN) field. This two bit SN allows for a modulo 4 style sequence 
10 numbering at the transmitter. In general, SN could start at 0 and follow the sequence 
of 1,2,3,0,1,2. 

Accordingly, if there is a packet loss, then the MINI-IP controller could 
detect the loss at individual user level and take appropriate actions specified by the 
operator. As can be seen, this 2 bit field allows packet loss protection of up to 3 

1 5 consecutive packets at IP layer. 

Fig. 8 illustrates the application 800 of MINI-IP being restricted to transport 
voice users between IP telephony gateways. Some of the most obvious scenarios 
800 are shown in Fig. 8. Traditional telephony users such as PSTN 810 and PBX 
820 interconnected by IP telephone gateways 830 is an ideal scenario where MINI— 

20 IP improves the bandwidth efficiency of the IP network. MINI-IP can also be used 
in Radio Access Network (RAN) of a wireless network. 

Fig. 9 illustrates the application of a MINI-IP controller in a RAN 900. In 
this scenario, MINI-IP controller 910 is part of the BS 912 connected through IP 
network 920 to another MINI-IP controller 930 at the radio network controller/base 

25 station controller (RNC/BSC) 932. The base station controller 932 is coupled to a 
mobile switching center (MSC) 940 that includes a MINI-IP controller 942. The 
conversations of a number of GSM telephone users will be transported using IP 
telephony along with data traffic in the same IP network. Those skilled in the art 
will recognize that the present invention is not meant to be limited the particular 

3 0 components of the cellular system illustrated in Fig. 9. Rather, the MINI-IP is 

meant to be utilized in MINI-IP controllers in any component connected through a 
wireline or wireless IP network. 

As mentioned above, the important reason for multiplexing small packets 
into a single RTP payload is to reduce the RTP/UDP/IP overhead for each packet. 

35 For example, the overhead is 66.7% in case of 20 byte G.723.1 packet (40 byte 
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overhead/60 byte overhead + packet) and 80% for a 10 byte G.729 packet (40 byte 
overhead/50 byte overhead + packet). Considering that IP telephone gateways 
transfer hundreds of user at any given time, the overhead for all these users could 
very will exceed the total capacity of the link. However, the MINI-IP protocol 
5 described above reduces the overhead dramatically. 

Figs. 10-12 illustrate the differences in bandwidth requirement of MINI-IP 
and IP. The bandwidth requirement for a traditional scheme (RTP/UDP/IP) is 
compared to MINI-IP and the results are shown in Figs. 10 and 11. 

Fig. 10 is a plot 1000 of the number of users 1010 on a single RTP/UDP/IP 

10 connection versus the bandwidth in Kbps 1020 for G.723.1, whereas Fig. 1 1 is a plot 
1 100 of the number of users 1110 on a single RTP/UDP/IP connection versus the 
bandwidth in Kbps 1 120 for G.729. The rate of G.723.1 is 5.6 Kbps and the rate of 
G.729 is 8 Kbps. The actual bandwidth requirement for increasing number of users 
is calculated by simply multiplying the number of users and the peak bandwidth. 

1 5 For example, the actual bandwidth requirement for 10 G.723. 1 users is 56 Kbps. 
The bandwidth required by the traditional IP telephone method is calculated by 
adding the overhead of 66.7% (G.723.1) and 80% (G.729) per user. The bandwidth 
requirement for MINI-IP is calculated by adding the percentage of overhead due to 
multiplexing the number of users in a single UDP connection. The results indicate 

20 that the bandwidth requirement for transporting the same number of users through 
MINI-IP 1030, 1 130 is very low compared to the traditional IP (RTP/UDP/IP). 

The overhead 1200 of different speech codecs are shown in Fig. 12. The 
overhead due to RTP/UDP/IP is constant for both codecs since the RTP/UDP/IP 
overhead for each packet is constant. MINI-IP method is able to multiplex small 

25 packets into a single RTP/UDP/IP payload thus reducing the overhead to a 

minimum. The overhead due to MINI-IP 1230, 1240 on both codecs provides that 
MINI-IP is efficient in utilizing the bandwidth of the output link. In addition, as the 
number of users on a single connection increases, the overhead reduces further. 
Since MINI-IP utilize the bandwidth efficiently and does not generate as many 

30 individual IP packets, it avoids the congestion at intermediate IP routers. Also, high 
bandwidth efficiency allows the IP packets to be forwarded quickly within the 
network thus reducing the overall delay for speech packets. 

In summary, MINI-IP provides an increase in bandwidth efficiency between 
IP telephone gateways. MINI-IP allows many users to share a single RTP/UDP/IP 

35 connection, thus reducing the IP overhead for each packet. The codecs used in 
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telephone applications today generate an average packet size of 10 byte per speech 
sample. As shown above, the RTP/UDP/IP overhead per speech packet ranges from 
66% to 80%. This enormous overhead lowers the bandwidth efficiency as well as 
causes congestion by generating large number of short IP packets. Traditional IP 
5 telephony gateways that interconnects PSTN/GSM/PBX systems do not utilize the 
bandwidth efficiently, whereas MINI-IP allows a number of users to share a single 
connection thereby reducing the overhead per packet transmitted. The assembly and 
de-assembly processing is compensated in case of MINI-IP because it does not 
require any separate UDP connection and complex signaling. 

1 0 MINI-IP provides a second advantage of reducing the number of UDP 

connections between gateways by sharing a single RTP/UDP/IP The third advantage 
is that the MINI-IP method reduces the changes for congestion at intermediate IP 
routers. MINI-IP reduces the number of IP packets by multiplexing mini packets in 
a single RTP payload, which helps to lower the congestion at the routers as well as 

1 5 reduces the complexity of IP packet forwarding. 

The foregoing description of the exemplary embodiment of the invention has 
been presented for the purposes of illustration and description. It is not intended to 
be exhaustive or to limit the invention to the precise form disclosed. Many 
modifications and variations are possible in light of the above teaching. It is 

20 intended that the scope of the invention be limited not with this detailed description, 
but rather by the claims appended hereto. 
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WHAT IS CLAIMED IS: 

1 . A protocol for increasing the bandwidth usage efficiency of a IP 
telephone network comprising: 

creating a header for a plurality of data packets, each header providing 
5 identification of a user associated with a packet; 

adding each header to the data packet associated therewith to form mini-IP 
payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection. 

10 2* The protocol of claim 1 wherein the plurality of data packets are 

received from two or more users. 

3 . The protocol of claim 2 wherein the identification of a user further 
comprises a unique channel identifier for each of the two or more users. 

4. The protocol of claim 3 wherein the channel identifier is assigned to 
15 packets from a user when the user requests access to the IP telephone network. 

5. The protocol of claim 2 wherein the header comprises a length 
indicator, the length indicator indicating the size of the data packet associated with 
the header. 

6. The protocol of claim 5 wherein the length indicator comprises six 
20 bits for allowing a maximum of a thirty-two byte data packet. 

7. The protocol of claim 1 wherein the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 
user to identify data packet loss. 

8. The protocol of claim 7 wherein the sequence number further 

25 comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

9. The protocol of claim 1 wherein the header of each data packet 
multiplexed into the RTP payload is transparent to intermediate IP routers. 

18 
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10. The protocol of claim 1 further comprising de 
payload back into the data packets. 
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^-assembling the RIP 



1 1 . The protocol of claim 1 further comprising: 
receiving at a local gateway an access request from a user at a remote 5P 
5 gateway; 

transmitting a setup message to the remote IP gateway using an IP 
connection; and 

establishing a user plane connection for receiving data packets from asiser 
after successful completion of a connection setup. 

10 12. The protocol of claim 1 1 further comprising: 

after receiving an access request from a user, determining whether an 
existing RTP/UDP/IP connection is available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDMP 
connection is determined to be available; 
1 5 creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 

connection is determined not to be available; and 

creating a setup message using a local UDP port number, remote poit 
number, and channel identifier. 

13. The protocol of claim 12 further comprising: 

20 recovering, at the remote gateway, a local UDP port number, remote jort 

number, channel identifier from the setup message; 

verifying at the remote gateway whether the channel identifier is frees and 
accepting the connection when the channel identifier is free. 

14. The protocol of claim 1 3 wherein the accepting the connection further 
25 comprises: 

updating a channel identifier table at the remote gateway; 
replying to the local gateway with a connect message. 

15. The protocol of claim 14 further comprising replying to the hxtal 
gateway with a rejection message when a problem allocating the connection ©coirs. 
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1 6. The protocol of claim 1 4 further comprising: 
receiving at the local entity the connect message; 
confirming at the local entity the channel identifier; and 
informing the user requesting access. 



5 17. The protocol of claim 1 further comprising controlling the 

multiplexing and transmitting of the RTP payload using a timer. 

1 8. The protocol of claim 1 wherein the data packets comprise 
compressed voice data. 

19. An IP telephone network, comprising: 
10 a remote IP gateway; and 

a local IP gateway; 

wherein the remote and local IP gateways communicate using a protocol, the 
protocol comprising: 

creating a header for a plurality of data packets received from a 
1 5 plurality of users at the local IP gateway, each header providing identification of a 
user associated with a packet; 

adding each header to the data packet associated therewith to form 
mini-IP payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
20 transmitting the RTP payload over a single RTP/UDP/IP connection 

to the remote IP gateway. 

20. The IP telephone network of claim 19 wherein the identification of a 
user further comprises a unique channel identifier for each of the two or more users. 

21. The IP telephone network of claim 20 wherein the channel identifier 
25 is assigned to packets from a user when the user requests access to the remote IP 

gateway. 

22. The IP telephone network of claim 19 further comprising: 
receiving at the local IP gateway an access request from a user at the remote 

IP gateway; 
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transmitting a setup message to the remote IP gateway using an IP 
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connection; and 

establishing a user plane connection for receiving data packets frcaaaiser 
after successful completion of a connection setup. 

23. The IP telephone network of claim 22 further comprising: 

5 after receiving an access request from a user, determining whether^; 

existing RTP/UDP/IP connection between the local and remote IP gateways 
available; 

using an existing RTP/UDP/IP connection when an existing RTP/13B/IP 
connection is determined to be available; 
1 0 creating a new RTP/UDP/IP connection when an existing RTP/UBSP 

connection is determined not to be available; and 

creating a setup message using a local UDP port number, remote ptfc 
number, channel identifier. 

24. The IP telephone network of claim 23 further comprising: 

1 5 recovering, at the remote IP gateway, a local UDP port number, reafce port 

number, channel identifier from the setup message; 

verifying at the remote IP gateway whether the channel identifieraiSe; and 
accepting the connection when the channel identifier is free. 

25. The IP telephone network of claim 24 wherein the accepti^&e 
20 connection further comprises: 

updating a channel identifier table at the remote IP gateway; 
replying to the local IP gateway with a connect message. 

26. The IP telephone network of claim 25 further comprising Aging to 
the local IP gateway with a rejection message when a problem allocating ife 

25 connection occurs. 

27. The IP telephone network of claim 25 further comprising: 
receiving at the local IP gateway the connect message; 
confirming at the local IP gateway the channel identifier; and 
informing the user requesting access. 
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28. The IP telephone network of claim 1 9 wherein the data packets 
comprise compressed voice data. 



29. A MINI-IP controller, comprising: 

means for providing control plane signaling, control plane signaling being 
5 used to setup a connection to a remote peer MINI-IP controller; and 

means for providing user plane signal, user plane signaling being used to 
transmit data packets to a user associated with the remote peer MINI-IP controller 
using a MINI-IP protocol, the MINI-IP protocol comprising: 

creating a header for a plurality of data packets, each header 
10 providing identification of a user associated with a packet; 

adding each header to the data packet associated therewith to form 
mini-IP payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection. 

15 30. The MINI-IP controller of claim 29 wherein the data packets 

comprise compressed voice data. 

3 1 . An RTP payload, comprising: 
an RTP header; 

a plurality of data packets representing data from a plurality of users; and 
20 a plurality of MINI-IP headers, each of the plurality of packets having a 

MINI-IP header attached thereto, each of the MINI-IP headers comprising a user 
identifier for identifying one of the plurality of users being associated with each of 
the packets, and each MINI-IP header and packet combination forming a MINI-IP 
payload, the MINI-IP payloads being multiplexed together to form a RTP packet. 

25 32 - The RTP payload of claim 3 1 further comprising a UDP header. 

33. The RTP payload of claim 32 further comprising an IP header, 

34. The RTP payload of claim 3 1 wherein the identifier of a user further 
comprises a unique channel identifier for each of the two or more users. 
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35. The RTP pay load of claim 34 wherein the channel ideriS 
assigned to packets from a user when the user requests access to an IPttlne 
network. 

36. The RTP payload of claim 35 wherein the MINI-IP heaifaiprises 
5 a length indicator, the length indicator indicating the size of the data pj& 

associated with the header. 

37. The RTP payload of claim 36 wherein the length indicataprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

38. The RTP payload of claim 3 1 wherein the MINI-IP heafifcher 
1 0 comprises a sequence number, the sequence number marking data padar 

transmitted from a user to identify data packet loss. 

39. The RTP payload of claim 38 wherein the sequence nurafcther 
comprises two bits, the two bits identifying a maximum of three conseaiata 
packet losses. 

1 5 40. The RTP payload of claim 3 1 wherein the MINI-IP hea&iack 

data packet multiplexed into the RTP payload is transparent to intermeft 
routers. 

41 . The RTP payload of claim 3 1 wherein the data packetsan(se 
compressed voice data. 

20 42. An IP network, comprising: 

a base station having a MINI-IP controller; and 
a RNC having a MINI-IP controller; 

wherein the base station and the RNC communicate using a prfjihe 
protocol comprising: 
25 creating a header for a plurality of data packets received* 

plurality of users at the RNC, each header providing identification of aw 
associated with a packet; 

adding each header to the data packet associated therewfbim 
mini-IP payloads; 
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multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection 
to the base station. 

43 . The IP network of claim 42 wherein the identification of a user 
5 further comprises a unique channel identifier for each of the two or more users. 

44. The IP network of claim 43 wherein the channel identifier is assigned 
to packets from a user when the user requests access to the base station. 

45. The IP network of claim 42 further comprising: 

receiving at the RNC an access request from a user at the base station; 
10 transmitting a setup message to the base station using an IP connection; and 

establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

46. The IP network of claim 45 further comprising: 

after receiving an access request from a user, determining whether an 
1 5 existing RTP/UDP/IP connection between the RNC and base station is available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined to be available; 

creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined not to be available; and 
20 creating a setup message using a local UDP port number, remote port 

number, channel identifier. 

47. The IP network of claim 46 further comprising: 
recovering, at the base station, a local UDP port number, remote port 

number, channel identifier from the setup message; 
25 verifying at the base station whether the channel identifier is free; and 

accepting the connection when the channel identifier is free. 

48. The IP network of claim 47 wherein the accepting the connection 
further comprises: 

updating a channel identifier table at the base station; 
30 replying to the RNC with a connect message. 
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49. The IP network of claim 48 further comprising replying taibeR3KBC 
with a rejection message when a problem allocating the connection occurs. 



50. The IP network of claim 48 further comprising: 
receiving at the RNC the connect message; 

5 confirming at the RNC the channel identifier; and 

informing the user requesting access. 

5 1 . The IP network of claim 42 wherein the data packets comprae 
compressed voice data. 

52. A base station having a MINI-IP controller for increasing fte 
10 efficiency of bandwidth usage in a cellular network, the MINI-IP controller 

comprising means for providing control plane signaling, control plane sigiiifig 
being used to setup a connection to a base station controller having apeer HHUDf ' 
controller and means for providing user plane signal, user plane signaling heig raft 
to transmit data packets to a the base station controller using a MINI-IP pUotcol* 
15 the MINI-IP protocol creating a header for a plurality of data packets, each&adsr 
providing identification of a mobile user associated with a packet, adSwgsM 
header to the data packet associated therewith to form mini-IP payloads, 
multiplexing the mini-IP payloads into a RTP payload and transmitting tb&TP 
payload over a single RTP/UDP/IP connection. 

20 53 . The base station of claim 52 wherein the data packets amxpm 

compressed voice data. 

54. A base station controller having a MINI-IP controller fer ireasiiBg 
the efficiency of bandwidth usage in a cellular network, the MINI-IP coEfibfir 
comprising means for providing control plane signaling, control plane sagntfg 

25 being used to setup a connection to a base station having a peer MINHPcfcblkir 
and means for providing user plane signal, user plane signaling beingBss&m 
transmit data packets to a the base station using a MINI-IP protocol, &e&BHP 
protocol creating a header for a plurality of data packets, each headerjsttral 
identification of a mobile user associated with a packet, adding eachbsa£kD3hfr 

30 data packet associated therewith to form mini-IP payloads, multiplex^ itaim-IP 
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payloads into a RTP payload and transmitting the RTP payload over a single 
RTP/UDP/IP connection. 



55. The base station controller of claim 52 wherein the data packets 
comprise compressed voice data. 

5 .56. A mobile switching center having a MINI-IP controller for increasing 

the efficiency of bandwidth usage in a cellular network, the MINI-IP controller 
comprising means for providing control plane signaling, control plane signaling 
being used to setup a connection to a base station controller having a peer MINI-IP 
controller and means for providing user plane signal, user plane signaling being used 

10 to transmit data packets to a the base station controller using a MINI-IP protocol, 
the MINI-IP protocol creating a header for a plurality of data packets, each header 
providing identification of a mobile user associated with a packet, adding each 
header to the data packet associated therewith to form mini-IP payloads, 
multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP 

15 payload over a single RTP/UDP/IP connection. 

57. The mobile switching center of claim 52 wherein the data packets 
comprise compressed voice data. 
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